Use iptables 1.4.14 with kernel 2.6.22 #7
Conversation
kjbracey2
force-pushed
the
iptables-1.4
branch
2 times, most recently
from
0f09ef8 to
6b08209
Compare
|
Updated to incorporate a couple of later 2.6.25 bug fixes in xt_conntrack. I'd cherry-picked the initial commits, but not checked against the final release version. I've now crosschecked with the linux-stable 2.6.25.y and 2.6.36.y branches to ensure all relevant bits are in - doesn't seem there were any backport fixes. |
Pull in kernel 2.6.25 code supporting xt_conntrack revision 1. This provides IPv6 conntrack support for iptables-1.4.x, and hence IPv6 QoS support.
And adjust iptables (1.3.8) to match. This gives user-space compatibility between kernel 2.6.22 and 2.6.38.
kjbracey2
force-pushed
the
iptables-1.4
branch
from
6b08209 to
6e30aaf
Compare
|
Updated to include backport of xt_MARK rev 2. The 2.6.22 kernel and iptables were using hacked rev 0/1 to let this work (from commit df49fc2), but iptables-1.4.x doesn't know about this. Giving the kernel rev 2 lets iptables-1.4.x use its standard rev 2 implementation, and avoids it being confused by the kernel's modified rev 0/1. |
MARK revision 0 and revision 1's SET operations had been hacked to act like revision 2 (AND+XOR), and iptables had been hacked to take advantage of this, so that rules could use masks. iptables-1.4.14 doesn't have this hack, so won't permit masks. It only knows how to do them with revision 2. It also will be expecting revision 0 and 1 to work as normal. Extend the kernel so it provides revision 2, allowing iptables-1.4.14's standard support to work. This should also avoid potential problems with its standard use of revision 0 and 1 being misinterpreted by the hacked kernel - it will use revision 2.
File exists twice in iptables/xtoptions.c (old location as found in GPL) and libxtables/xtoptions.c (new location for 1.4.14). Delete from the old location, and incorporate the manual number conversion fallback in the new location (which seems to be necessary in the RT-N66U).
kjbracey2
force-pushed
the
iptables-1.4
branch
from
6e30aaf to
97b90d7
Compare
|
The point of all of this was to get IPv6 QoS working - the initial blocker was Now this PR is doing the job, and updating a bunch of things to do it, but I've realised there are two much simpler approaches.
Not tested either of those though. |
|
Would hashlimit work with this patch? |
These patches make IPv6 QoS work on routers using 2.6.22.